IP Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc, within the same session. By growing the numbers of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP).
User equipment (UE) may comprise or represent any device used for communications. Examples of user equipment that may be used in certain embodiments of the described access networks are wireless devices such as mobile phones, terminals, smart phones, portable computing devices such as lap tops, handheld devices, tablets, netbooks, computers, personal digital assistants and other wireless communication devices.
FIG. 1a illustrates schematically a communications network architecture 100 including an IMS network 102, a first access network 104 such as an Long term evolution (LTE)/LTE Advanced access network and a second access network 106 such as a Global System for Mobile Communications (GSM)/Wideband Code Division Multiple Access (VVCDMA) access network. Signals are directed to/from a user equipment 108 (UE-A), which initially communicates with the first access network 104 and a public address safety point (PSAP) 110 through the IMS network 102 during an ECS. The network entities or nodes within the first access network 104 connect the UE-A 108, which is an IMS subscriber, to IMS services provided by the IMS network 102. The first access network 104 includes various support nodes such as eNodeB base station(s) 112, which may connect via a Mobility Management Entity (MME) node 114 to a Mobile Switching Center (MSC) node 122 of the second access network 106, or connects via a Serving Gateway and Packet Data Network Gateway node (S&P GW) 116 to network entities or nodes (described below) of the IMS network 102. The second access network 106 may be a GSM/WCDMA network that includes various support entities or nodes such as a NodeB base station node (BTS NodeB) 118 that communicates with a Base Station Controller/Radio Network controller node (BSC/RNC) 120 and MSC node 122, which acts as an interface between the GSM/WCDMA backbone network, the first access network 104 and the IMS network 102.
The IMS network 102 includes network entities or nodes that send/receive signals to/from the first and second access networks 104 and 106, these nodes connect with the first and second access networks 104 and 106 via the S&P GW and MSC nodes 116 and 122. The IMS network nodes include Call/Session Control Function (CSCF) nodes, which operate as SIP proxies within the IMS network 102. The 3GPP architecture defines several types of CSCF nodes: the Proxy CSCF (P-CSCF) node 124 which is typically the first point of contact within the IMS network 102 for UE 108, which is SIP enabled; the Serving CSCF (S-CSCF) node provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) node 126 whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from UE-A 108 via P-CSCF node 124. For simplicity, FIG. 1a shows the S-CSCF combined with the I-CSCF node 126.
The IMS network 102 also includes the multimedia gateway control function (MGCF) node 128, which acts as an interface between the second access network 106 and the IMS network 102, the MGCF node 128 performs call control protocol conversion between SIP messages and ISUP/BICC messages. It translates non-SIP signalling messages (ISUP/BICC) from the MSC node 122 into SIP messages used in the IMS network 102. The Service Centralization and Continuity Application Server (SCC-AS) 130 performs access domain selection and service domain selection for deciding the type of access network, packet switched or circuit switched network access, an IMS subscriber such as UE-A 108 may require. It also supports session anchoring and session and access transfer functionality. The IMS network 102 also includes an Access Transfer Control Function (ATCF), which is a signalling controller that, in this case, is incorporated with P-CSCF node 124. The Access Gateway and Access Transfer Gateway (AGW/ATGW) node 132 is a media anchor point. These facilitate rapid and predictable handover of a call session of UE-A 108 from the first access network 104 to the second access network 106 (i.e. from an LTE or LTE-Advanced network to circuit 2G/3G networks) and are used to update the necessary servers after an access transfer. This provides seamless call handover between the first access network 104 and the second access network 106 by reducing the number of network nodes for handover of an active voice call to the new access network.
In FIG. 1a the IMS network 102 is arranged for implementing IMS emergency services and further includes an Emergency CSCF (E-CSCF) node 134, a Location Retrieval Function (LRF) node 136, and an Emergency Access Transfer Function (EATF) node 138. For simplicity, not all functional components of the IMS network 102, e.g. the Interconnection Border Control Function (IBCF) and Breakout Gateway Control Function (BGCF) nodes, are shown in these or the following figures.
FIG. 1b is a signalling flow diagram illustrating an IMS emergency call (EC) setup of an ECS when UE-A 108 initiates an EC from the first access network 104. Initially, UE-A 108 places the EC when connected to the first access network 104 by sending a SIP Invite message including an International Mobile Equipment Identity (IMEI) number of UE-A 108 e.g. Invite (urn: service:sos; contact:+sip.instance=“<“IMEI”>”). The EC setup signalling flow shows the EC signalling being routed from UE-A 108 through the support nodes of the first access network 104 to the P-CSCF node 124 and then to the E-CSCF node 134. The E-CSCF node 134 is concerned with handling ECSs and is responsible for the routing of ECs to the correct emergency centre or PSAP 110. The E-CSCF node 134 has an interface to the LRF node 136, and the E-CSCF node 134 requests the LRF node 136 to retrieve location information relating to UE-A 108. The LRF node 136 also provides the E-CSCF with the PSAP 110 destination address. The E-CSCF node 134 also has an interface to the EATF node 138, which enables service continuity of IMS EC services and sessions. The E-CSCF node sends a SIP Invite request message including the IMEI to the EATF node 138, e.g. Invite (urn:service:sos; contact:+sip.instance=“<“IMEI”>”; route: EATF-URI; Route: E-CSCF-URI). The ECS of UE-A 108 is then anchored at EATF node 138.
According to 3GPP TS 24.229, when the EATF node 138 receives the SIP INVITE request with an emergency service uniform resource name (URN), the EATF node 138 stores the SIP INVITE request, anchors the ECS, acts as a specified node for a routing back-to-back user agent (B2BUA), and provides access or session transfer functionality until the ECS of UE-A 108 is terminated. The ECS of UE-A 108 is said to be known to, or known by, EATF node 138 when the EATF node 138 has stored the SIP INVITE request in relation to ECS of UE-A 108 and/or the ECS of UE-A 108 has been anchored by EATF node 138. The ECS of UE-A 108 is said to be unknown to, or unknown by, EATF node 138 when it has not stored the SIP INVITE request in relation to ECS of UE-A 108 and/or the ECS of UE-A 108 has not been anchored by EATF node 138.
The P-CSCF node 124, EATF node 138 and E-CSCF node 134 are located in the same serving network, which is the visited network when the UE-A 108 is roaming. Once anchored, the E-CSCF and EATF nodes 134 and 138 proceed with the EC setup to connect the ECS between UE-A 108 and PSAP 110.
Single Radio Voice Call Continuity (SRVCC) handover (HO) is described in 3GPP TS 23.237 and 3GPP TS 23.216, and allows handover of a voice call from the first access network 104 to the second access network 106, for example from packet switched access to circuit switched access (e.g. transfer of a VoIP IMS session from an E-UTRAN to a UTRAN/GERAN). During the ECS of UE-A 108, when the ECS is used in combination with SRVCC, the E-CSCF node 134 can invoke the EATF node 138, which is anchoring the ECS of UE-A 108 in the serving network, to transfer the ECS from the first access network 104 (e.g. a packet switched network) to the second access network 106 (e.g. a circuit switched network). EATF node 138 ensures that the new call leg over the second access network 106 (i.e. the Target Access Leg) is correlated with the ongoing ECS between UE-A 108 and PSAP 110 and is transferred correctly and seamlessly. The EATF node 138 enables SRVCC HO for the ECS from the first access network 104 (e.g. a packet-switched (PS) LTE/LTE Advanced access network) to the second access network 106 (e.g. a circuit switched (CS) GSM/WCDMA access network).
FIG. 1c is a signalling flow diagram illustrating an example of a session transfer (also known as a transfer or handover) of an IMS ECS of UE-A 108 from the first access network 104 to the second access network 106. As illustrated in FIG. 1b, when an IMS EC setup with the home network is performed the EATF node 138 within the serving network is the only node for anchoring the EC signalling and ECS in voice over LTE (VoLTE) deployments. In this example, the ECS is known to the EATF node 138 as it is the only EATF node that can anchor the ECS of UE-A 108. VoLTE EC signalling will traverse from the Radio and Enhanced Packet Core (EPC) nodes (e.g. eNodeB 112 and S&P GW 116) of the first access network 104 to the P-CSCF node 124, E-CSCF node 134 (or BGCF), EATF node 138, back to E-CSCF node 134 and then toward PSAP 110 directly or via a gateway, for example, an MGCF 128 or IBCF node (not shown). If there is a gateway such as an MGCF 128 or IBCF between IMS network 102 and PSAP 110, the media will pass through a Media Gateway (MGW) if signalling was through the MGCF 128, or the media will pass through a Translation gateway (TrGW) if signalling was sent through an IBCF node (not shown). MGCF 128 is the interconnecting gateway between IMS network 102 and the second access network 106 e.g. GSM/WCDMA or other PSTN/PLMN legacy CS networks. IBCF is the interconnecting gateway between the IMS network 102 and other IP networks e.g. another IMS network or similar.
Referring to FIGS. 1a and 1c, it is assumed that IMS EC setup as shown in FIG. 1b has been completed and that an ECS between UE-A 108 and PSAP 110 is ongoing via the IMS network 102 and first access network 104. The ECS of UE-A 108 originated in the IMS network 102 and has been anchored in the EATF node 138, optionally via MGCF/IBCF. However, as UE-A 108 may move from the first access network 104 to the second access network 106, an EC SRVCC HO decision may be used to initiate an emergency handover in eNodeB 112, which uses MME node 114 to trigger the MSC node 122 of the second access network 106 to begin the handover. The EC SRVCC is initiated by the eNodeB 112 (or EPC) with similar mechanisms as a normal SRVCC (described in 3GPP TS 23.216). The MME node 114 will indicate to the MSC node 122 that a session transfer is for the ECS of UE-A 108 is required, this indication may include the IMEI and/or possibly the Correlation Mobile Subscriber Integrated Services Digital Network Number (C-MSISDN). The MME node 114 only executes SRVCC for emergencies if an emergency voice bearer exists.
The MSC node 122 uses a locally configured emergency-session transfer number-SRVCC (E-STN-SR) for use by the IMS network 102 in performing the handover. The MSC node 122 has one configured E-STN-SR (as there is one logical EATF node 138 per MSC node 122) and sends a session transfer request including the IMEI (as part of sip.instance feature tag) to the IMS network 102 and EATF node 138. For example, the MSC node 122 sends as the session transfer request the SIP message Invite (E-STN-SR, SDP MGW, Contact:+sip.instance=“<“IMEI”>”, PAI: C-MSISDN (if available)). The MSC node 122 could also send the session transfer request using ISUP messaging toward MGCF node 128, e.g. an ISUP IAM message including the IMEI could be sent as specified in 3GPP TS 29.163. In any event, this session transfer request goes through the IMS network 102 via the I-CSCF node 126 and to the EATF node 138. The E-STN-SR in the IMS network 102 can be configured as a Public Service Identity (PSI), and stored in the home subscriber server (HSS) (not shown). The EATF node 138 acts as a routing B2BUA and provides access or session transfer functionality. The EATF node 138 then performs a SDP re-negotiation toward PSAP 110 to change the SDP of UE-A 108 from S&P GW 116 to a SDP received from the MSC node 122 and other subcomponents such as the MGW (not shown). The EATF node 138, P-CSCF node 124 and E-CSCF node 134 from an EC point of view are always located in the serving network.
However, according to the 3GPP standards, only one logical EATF node is defined per network or MSC node 122 or for each PSAP 110. However, in many real deployments, this is not sufficient due to increases in congestion and load within telecommunication networks. The EATF address, an E-STN-SR according to 3GPP TS 23.237 is an E.164 number, is configured on all the MSC nodes 122. This implies that the serving PLMN is assumed to have a single logical EATF. In future telecommunications networks, multiple EATF nodes per network region may be required for meeting future capacity requirements, providing geographic redundancy when EATF nodes in a particular geographic region are overloaded or fail, or when multiple PSAPs are used in the same network such that an EATF node or function is placed close to each PSAP.
As current 3GPP standards define only one single E.164 number for an ECS, this means that current EATF nodes are selected based on normal Domain Name Server (DNS) procedures with no special “intelligence” used to find the correct EATF node. Currently this is usually not an issue because there is only one EATF node used per PSAP or network region. However, with the introduction of multiple EATF nodes per PSAP or network region to alleviate the above future issues, current DNS procedures will not be sufficient to find the correct EATF node anchoring the ECS of a UE and the probability of ending up sending a request to transfer an ECS to the “wrong” EATF node will be high. This may result in call delays or even cut-off of an existing ECS if handover cannot be completed promptly.
A possible solution could be based on picking a certain EATF node in the IMS network at IMS registration and call setup and at handover use a redirect model such that should the wrong EATF node be addressed, then the I-CSCF node either rejects/redirects the ECS to another EATF node until the correct one has been found. Such a model would require additional standardization and a greater level of network node redesign and integration throughout the IMS network. Therefore, there is a need for a reliable scalable solution that enables the correct instance of an EATF node to be found during an ECS transfer given the single locally configured E-STN-SR for the MSC node, while at the same time reducing the requirement to modify existing CSCF nodes in the IMS network.